new plugin: safe_autoenv #2354

oz123 · 2025-10-08T15:01:06Z

Exports variables from .env when starting a shell or cd'ing to a directory.
When leaving the directory the variables from .env will be unset.

Given:

$ mkdir -pv /tmp/foo/bar/baz
mkdir: created directory '/tmp/foo'
mkdir: created directory '/tmp/foo/bar'
mkdir: created directory '/tmp/foo/bar/baz'
$ echo CLOWN=sideshowbob > /tmp/foo/bar/baz/.env
$ echo MASTER_CLOWN="Krusty the Clown" > /tmp/foo/bar/.env

$ cd /tmp/foo/bar/baz/
Processing /tmp/foo/bar/.env
Processing /tmp/foo/bar/baz/.env
$ cd ../
Unsetting CLOWN (from /tmp/foo/bar/baz)
$ cd baz/
Processing /tmp/foo/bar/baz/.env
cd ../../
Unsetting MASTER_CLOWN (from /tmp/foo/bar)
Unsetting CLOWN (from /tmp/foo/bar/baz)

Description

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):

Types of changes

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

My code follows the code style of this project.
If my change requires a change to the documentation, I have updated the documentation accordingly.
I have read the CONTRIBUTING document.
If I have added a new file, I also added it to clean_files.txt and formatted it using lint_clean_files.sh.
I have added tests to cover my changes, and all the new and existing tests pass.

Exports variables from .env when starting a shell or cd'ing to a directory. When leaving the directory the variables from .env will be unset. Given: $ mkdir -pv /tmp/foo/bar/baz mkdir: created directory '/tmp/foo' mkdir: created directory '/tmp/foo/bar' mkdir: created directory '/tmp/foo/bar/baz' $ echo CLOWN=sideshowbob > /tmp/foo/bar/baz/.env $ echo MASTER_CLOWN="Krusty the Clown" > /tmp/foo/bar/.env $ cd /tmp/foo/bar/baz/ Processing /tmp/foo/bar/.env Processing /tmp/foo/bar/baz/.env $ cd ../ Unsetting CLOWN (from /tmp/foo/bar/baz) $ cd baz/ Processing /tmp/foo/bar/baz/.env cd ../../ Unsetting MASTER_CLOWN (from /tmp/foo/bar) Unsetting CLOWN (from /tmp/foo/bar/baz) Signed-off-by: Oz Tiram <oz.tiram@gmail.com>

plugins/available/safe_autoenv.plugin.bash

seefood · 2025-10-11T16:08:55Z

@oz123 ?

**safe_autoenv.plugin.bash:** - SC2207: Added shellcheck disable for array assignment from command substitution - SC2155: Separated declaration and assignment for env_dir variable **artisan.completion.bash:** - SC2034: Removed unused disable comment for 'commands' variable - SC2016: Changed single quotes to double quotes for proper variable expansion All shellcheck warnings resolved. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>

seefood · 2025-10-11T19:13:46Z

Fixed shellcheck warnings (SC2207, SC2155) and artisan completion issues (SC2034, SC2016). All pre-commit hooks now pass. ✅

oz123 · 2025-10-12T10:25:57Z

Hi! Thanks for fixing the stuff for me. I already did some of it but have not pushed it.
Does that mean you are going to merge it? anything else needed?

akinomyoga

I just quickly checked. I haven't checked the logics.

completion/available/artisan.completion.bash

akinomyoga · 2025-10-12T10:40:16Z

plugins/available/safe_autoenv.plugin.bash

+declare _AUTOENV_LAST_PWD=""       # Track last working directory
+
+_autoenv_init() {
+	typeset target home _file current_dir


typeset is used here, while local is used elsewhere. This should be normalized.

akinomyoga · 2025-10-12T10:43:54Z

plugins/available/safe_autoenv.plugin.bash

+	home="${HOME%/*}"
+
+	# shellcheck disable=SC2207
+	_files=($(


This doesn't work when the directory path contains spaces or glob characters. It is better to use while [[ ... ]]; do ... _files+=("${_file}") ... done than to echo the filename and split it using _files=($(...)).

akinomyoga · 2025-10-12T10:51:48Z

plugins/available/safe_autoenv.plugin.bash

+			# Validate key name (additional safety check)
+			if [[ ! "$key" =~ ^[A-Za-z_][A-Za-z0-9_]*$ ]]; then
+				echo "Warning: Invalid variable name '$key' at line $line_number in $env_file" >&2
+				continue
+			fi


In what situation does this happen? I think key is supposed to contain a valid key name in this context.

akinomyoga · 2025-10-12T10:55:35Z

plugins/available/safe_autoenv.plugin.bash

+			# Handle quoted values (remove outer quotes if present)
+			if [[ "$value" =~ ^\"(.*)\"$ ]]; then
+				value="${BASH_REMATCH[1]}"
+			elif [[ "$value" =~ ^\'(.*)\'$ ]]; then
+				value="${BASH_REMATCH[1]}"
+			fi
+
+			# Export the variable silently
+			export "$key=$value"


This fails when value contains escape sequences such as key="\"". This fails when value contains multiple '...' pairs, such as key='abc'\''def'. This can simply be

Suggested change

# Handle quoted values (remove outer quotes if present)

if [[ "$value" =~ ^\"(.*)\"$ ]]; then

value="${BASH_REMATCH[1]}"

elif [[ "$value" =~ ^\'(.*)\'$ ]]; then

value="${BASH_REMATCH[1]}"

fi

# Export the variable silently

export "$key=$value"

# Export the variable silently

eval "export $line"

I think Oz meant that it unsets vars once you CD out of a directory, however I don't see how it restores a previous value. needs a stack and all.

I now guess that the above part of the code corresponds to the safety.

A typical vulnerability of this type of configuration (such as direnv and autoenv) is that it can load a malicious environment just by cd'ing into the directory. For example, one may download a wild tarball from the internet, extract it, and cd into the directory, assuming that just cd'ing into the directory doesn't execute any code from the tarball. However, if the environment contains key=$(some malicious code), a naive implementation of eval may execute the malicious code.

However, even if the code were not directly executed when the environment is loaded, there are many variables that may be interpreted as commands and executed by applications, such as LESSOPEN, EDITOR, VISUAL, PAGER, etc. Or, LD_PRELOAD in Linux can be used to inject code on an arbitrary exec call. Just setting an environment value in the form export key="$value" isn't actually so safe.

To solve the issue, the framework should require the user to explicitly trust each directory environment (.env) by running something like autoenv trust <dir> and manage the list of sha256 codes of the trusted .env in a safe directory. Or there might be another approach, but I don't have an idea now.

I don't quite understand the use of repeating the export (or using eval "export ..." if the code is changed to that) here. If the user chooses to write GITHUB_TOKEN=..., I think it would be unexpected for that to be silently converted to an environment variable.

As @akinomyoga mentioned there are security concerns, and autoenv already has a system for allowing or disabling the sourcing of files by their checksum. I think duplicating that here just so some variables are marked as "exported" would be a lot of duplicate work and potentially confusing for the end user.

akinomyoga · 2025-10-12T11:00:02Z

plugins/available/safe_autoenv.plugin.bash

+			;;
+		"status")
+			echo "Processed directories:"
+			for dir in "${!_AUTOENV_PROCESSED_DIRS[@]}"; do


dir is not localized.

akinomyoga · 2025-10-12T11:00:13Z

plugins/available/safe_autoenv.plugin.bash

+			done
+			echo
+			echo "Variable sources:"
+			for var in "${!_AUTOENV_VAR_SOURCES[@]}"; do


var is not localized.

akinomyoga · 2025-10-12T11:08:07Z

I guess @hyperupcall (who is a contributor of Bash-it and also the maintainer of autoenv) may give good suggestions.

By the way, the plugin name contains safe, but what kind of safety does it indicate?

seefood · 2025-10-12T12:36:56Z

Does that mean you are going to merge it? anything else needed?

Yes, I am just about to publish 3.2.0 and if it's fixed by Friday (see all the remarks from @akinomyoga ) it will be in there. have a go...

seefood · 2025-10-12T12:51:56Z

but what kind of safety does it indicate?

I think Oz meant that it unsets vars once you CD out of a directory, however I don't see how it restores a previous value. needs a stack and all.

plugins/available/safe_autoenv.plugin.bash

akinomyoga · 2025-10-12T13:12:50Z

plugins/available/safe_autoenv.plugin.bash

+	# Reinitialize arrays
+	declare -A _AUTOENV_PROCESSED_DIRS
+	declare -A _AUTOENV_DIR_VARS
+	declare -A _AUTOENV_VAR_SOURCES


This doesn't do what is intended. This doesn't initialize global associative arrays. This creates local associative arrays, which are never referenced later. To achieve what is expected, one needs to specify the -g flag, but it requires Bash 4.2+, which is an even stronger requirement than 3.2+.

seefood · 2025-10-13T07:35:52Z

Summary of findings:

Runtime code requiring bash 3.3+:

plugins/available/pack.plugin.bash - ✅ Now has version check added (PR Add bash 4+ version check to pack plugin #2358)
- Uses associative arrays (declare -A) requiring bash 4.0+
- Already had inline checks on lines 162 and 230 for bash > 3
plugins/available/history-eternal.plugin.bash:4 - ✅ Already has version check
- Requires bash 4.3+ for unlimited history
- Returns early with warning if version < 4.3
plugins/available/percol.plugin.bash:18 - ✅ Already has version check
- Requires bash 4.0+
- Returns early with warning if version < 4
vendor/github.com/gaelicWizard/bash-progcomp/defaults.completion.bash:51 - Vendor file (excluded from linting)
- Has bash 4.0 check but only for performance optimization
- Falls back to bash 3 compatible code

All runtime plugins requiring bash 3.3+ now have appropriate version checks and early returns.

akinomyoga · 2025-10-13T10:12:57Z

Thank you for your investigations!

For pack.plugin.bash: OK, I haven't noticed there is an existing check for the version check in pack.plugin.bash. It seems intentional that declare -A flaghash 2> /dev/null in pack.plugin.bash (where the error message is suppressed by the redirection to /dev/null) causes an error in Bash < 4.0. If so, it probably works without checking the Bash version at the beginning of the file.

I checked how the associative arrays flaghash and aliashash are used in pack.plugin.bash. However, flaghash is set but not referenced anywhere. Conversely, aliashash is referenced but not set anywhere. If that is true, it seems to me that we can safely remove all codes related to flaghash and aliashash. But maybe I missed something. @seefood Do you have an idea?

akinomyoga · 2025-10-13T10:15:35Z

Anyway, we need a Bash version check also for this new plugin (as long as declare -A is used).

seefood · 2025-10-13T10:44:25Z

seems to me that we can safely remove all codes related to flaghash and aliashash

I'll read it a bit later, I have a feeling shellcheck would have caught any problems like that.

However, right now I am glued to the TV, as a long war is coming to an end here and it's a happy news day I can't easily rip myself out of and do work :)

hyperupcall

This looks like to be a useful plugin, the main autoenv project does not implement unset-ing of variables or cleaning up in general when leaving directories. But I think the name "safe_autoenv " is a bit misleading. Yes, this code unsets variables that are set, but it also silently exports variables as environment variables, which potentially exposes more processes to that possible secret data. Perhaps "autounset-autoenv" or "autocleanup-autoenv" fit better?

To the bash-it maintainers: Would it be possible to note somewhere that this optionally "extends" autoenv and maybe compare it with the built-in AUTOENV_ENV_LEAVE_FILENAME? For example. our .env.leave requires manual unsettinng of variables, and this automatic detection is more convenient - but it also may cause unintended behavior. For example, if GITHUB_TOKEN is set in ~/.bashrc, and if it is overriden by a .env file, this code may unset it for the whole shell session unless ~/.bashrc is sourced again.

hyperupcall · 2025-10-14T20:17:43Z

plugins/available/safe_autoenv.plugin.bash

+			# Handle quoted values (remove outer quotes if present)
+			if [[ "$value" =~ ^\"(.*)\"$ ]]; then
+				value="${BASH_REMATCH[1]}"
+			elif [[ "$value" =~ ^\'(.*)\'$ ]]; then
+				value="${BASH_REMATCH[1]}"
+			fi
+
+			# Export the variable silently
+			export "$key=$value"


I don't quite understand the use of repeating the export (or using eval "export ..." if the code is changed to that) here. If the user chooses to write GITHUB_TOKEN=..., I think it would be unexpected for that to be silently converted to an environment variable.

As @akinomyoga mentioned there are security concerns, and autoenv already has a system for allowing or disabling the sourcing of files by their checksum. I think duplicating that here just so some variables are marked as "exported" would be a lot of duplicate work and potentially confusing for the end user.

hyperupcall · 2025-10-14T20:19:34Z

plugins/available/safe_autoenv.plugin.bash

+}
+
+# Public function for manual use
+autoenv() {


I would like to keep autoenv reserved in case the main autoenv project chooses to use it in the future. Perhaps safe-autoenv or safeenv are good alternatives?

hyperupcall · 2025-10-14T20:32:54Z

plugins/available/safe_autoenv.plugin.bash

+			# Unset each variable from this directory
+			for var in $var_list; do
+				if [[ "${_AUTOENV_VAR_SOURCES[$var]}" == "$dir" ]]; then
+					echo "Unsetting $var (from $dir)"


I think it would be better UX if print statements were prefixed with "safe_autoenv" so it is clear who is printing to standard output when cding to different directoreis (people may also confuse it with autoenv if it is not prefixed)

hyperupcall · 2025-10-14T20:33:06Z

plugins/available/safe_autoenv.plugin.bash

+}
+
+# Clean up variables from directories we've left
+_autoenv_cleanup() {


I would prefer if the function were prefixed with something like _safe_autoenv_ so it's clear that this is separate from the main autoenv project

seefood · 2025-10-14T21:49:58Z

Perhaps "autounset-autoenv" or "autocleanup-autoenv" fit better?

LIFO direnv...

github-advanced-security bot found potential problems Oct 8, 2025

View reviewed changes

plugins/available/safe_autoenv.plugin.bash Fixed Show fixed Hide fixed

plugins/available/safe_autoenv.plugin.bash Fixed Show fixed Hide fixed

akinomyoga reviewed Oct 12, 2025

View reviewed changes

Merge branch 'master' into safe_autoenv

0a8c314

akinomyoga reviewed Oct 12, 2025

View reviewed changes

akinomyoga mentioned this pull request Oct 13, 2025

Add bash 4+ version check to pack plugin #2358

Merged

hyperupcall suggested changes Oct 14, 2025

View reviewed changes

new plugin: safe_autoenv #2354

Are you sure you want to change the base?

new plugin: safe_autoenv #2354

Uh oh!

Conversation

oz123 commented Oct 8, 2025

Description

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):

Types of changes

Checklist:

Uh oh!

Uh oh!

Uh oh!

seefood commented Oct 11, 2025

Uh oh!

seefood commented Oct 11, 2025

Uh oh!

oz123 commented Oct 12, 2025

Uh oh!

akinomyoga left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hyperupcall Oct 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

akinomyoga commented Oct 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

seefood commented Oct 12, 2025

Uh oh!

seefood commented Oct 12, 2025

Uh oh!

Uh oh!

akinomyoga Oct 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

seefood commented Oct 13, 2025

Uh oh!

akinomyoga commented Oct 13, 2025

Uh oh!

akinomyoga commented Oct 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

seefood commented Oct 13, 2025

Uh oh!

hyperupcall left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hyperupcall Oct 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

seefood commented Oct 14, 2025

Uh oh!

hyperupcall Oct 14, 2025 •

edited

Loading

akinomyoga commented Oct 12, 2025 •

edited

Loading

akinomyoga Oct 12, 2025 •

edited

Loading

akinomyoga commented Oct 13, 2025 •

edited

Loading

hyperupcall left a comment •

edited

Loading

hyperupcall Oct 14, 2025 •

edited

Loading